Да, это по-прежнему вектор атаки, хотя воздействие более ситуативно.
Вот надуманный сценарий, который расширяет предыдущие ответы, если форма требует проверки подлинности (и проще, если сайту все равно, если формы отправляются через POST или GET):
1) Атакующий использует CSRF для входа в систему жертвы с использованием учетных данных атакующего (например, ). Таким образом, злоумышленник передает форму жертве, и не имеет значения, если у жертвы нет учетной записи.
2) Злоумышленник использует другой CSRF для выполнения XSS для формы, которая запрашивает у жертвы некоторые учетные данные и т. Д. (Это - то, где должна произойти некоторая убедительная социальная инженерия, или у злоумышленника есть некоторый полезный JavaScript для использования в браузере Same Origin для сайт.)
Еще один надуманный сценарий, в котором уязвимая форма выполняет какое-то важное действие, например, перевод денег между счетами:
0) Уязвимая форма использует скрытые поля формы со случайными значениями для предотвращения CSRF. Злоумышленник не знает, что это за значения, и не может правильно настроить атаку.
1) Attacker создает полезную нагрузку CSRF, которая включает JavaScript для чтения случайных токенов csrf формы (т. Е. Извлекает их из DOM браузера).
2) Жертва заходит на сайт.
3) Злоумышленник заманивает жертву к полезной нагрузке CSRF, CSRF загружает запрос формы с правильными токенами csrf, потому что он выполняется в браузере жертвы, в том же самом источнике сайта жертвы и использует сеанс аутентификации жертвы. Злоумышленнику не нужно знать токены csrf, просто имейте возможность манипулировать полями формы, в которых они хранятся.
4) Злоумышленник получает выгоду от того, что жертва отправляет форму - никаких всплывающих окон или социальной инженерии не требуется, кроме как заманить жертву в полезную нагрузку CSRF, но форма должна сделать что-то «полезное» для злоумышленника.